A user owning a personal mobile device (e.g., smartphone, tablet, etc.) may want to install certain “workplace” mobile applications (e.g., email, calendar, etc.) relating to his work as an employee of a business on his mobile device rather than carry an additional mobile device for work purposes. In situations where an employer permits the user to utilize his personal mobile device to install and run a workspace application, the employer's IT department may need to impose certain security measures or policies on the user's personal device to ensure that enterprise data that is accessed or stored on the personal mobile device is secure. For example, the approaches described in U.S. patent application Ser. No. 13/595,881 filed on Aug. 27, 2012 and entitled “Method and System for Facilitating Isolated Workspace for Applications” (which is hereby incorporated by reference and referred to herein as the “'881 application”) utilize a management application locally resident on the mobile device to assist in imposing security policies only around workspace data and applications.
One way of accomplishing this goal is by modifying the workplace application to enforce any such security measures or policies. For example, an application that provides access to workplace email may be modified to require an additional authentication step prior to allowing the user to access such workplace email by asking the user to log in using their work-issued user ID and password. Such modification is a straightforward matter, if the application source code is available to the software developer charged with this task. However, developers typically do not have access to source code to third-party applications of the type that most. In that case, the software developer may find it necessary to modify the executable file for the third-party application.
When modifying an executable file using Objective C, the software developer may use a technique called method swizzling to point to an alternate implementation of a method at runtime. Method swizzling operates by applying introspection to access the default method implementation and then applying reflection to redirect the code to use the alternate implementation of the method. Introspection is a feature of certain programming languages to provide information about objects at runtime, such as names of methods of a class, type information for instance variables of a class, and the actual implementation (code) of methods of a class. Reflection is a feature of certain programming languages that enables a developer to perform a number of operations at runtime, such as adding new classes, adding methods to a class, and adding instance variables to a class. The actual redirection is accomplished by changing the value of a pointer within a structure for the method so that the pointer points to the location of the alternate implementation instead of the location of the default implementation. For example, a third-party developer of an application for the APPLE IOS platform may not have access to the source code for classes provided by the IOS platform, but APPLE IOS currently provides a function to redirect the selector for a method (i.e., the value of the element in the method structure that indicates the location of the implementation of the method) to point to an alternate implementation: method_exchangeImplementations (Method original, Method new)). However, if introspection and reflection are not supported or simply not available, an alternate technique to achieve redirection of method calls at runtime may be desirable.